如何自動檢查、建置與部署系統？

自動化流程的價值在於讓相同輸入經過相同檢查，產生可以追溯的建置成品（Artifact）與結果。把既有人工指令直接搬進自動化工具，只能減少輸入次數。如果流程沒有明確門檻、成品身分、停止條件與復原方式，錯誤也會更快進入下一個環境。

部署工具與環境限制應該已經先行確認，本章聚焦於如何把程式碼檢查、測試、建置、核准、部署及部署後驗證串成可重複流程。

區分持續整合、持續發布與持續部署

持續整合（Continuous Integration, CI）、持續發布（Continuous Delivery）與持續部署（Continuous Deployment）代表不同的自動化範圍。

採用持續發布不代表每次變更都會自動進入正式環境。採用持續部署也不代表取消核准與保護規則，核准可以成為自動化流程中的必要關卡。選擇範圍時要考慮變更風險、部署頻率、操作責任及正式環境限制。

先定義流程輸入與觸發條件

每種觸發方式都要對應明確目的，避免相同流程因入口不同而執行不一致的檢查。

流程必須驗證觸發來源。例如，正式部署只能接受受保護分支或發布標籤時，就要在進入部署工作前拒絕其他來源。人工重跑也要保存原始提交、成品與觸發原因，不能因重新執行而失去追溯關係。

讓快速檢查優先失敗

檢查順序應該先執行速度快、失敗後無須繼續的工作，再進入需要較多時間或外部相依項目的工作。常見順序如下：

1. 驗證必要檔案、版本資訊與設定結構。
2. 執行格式檢查、程式碼檢查與靜態分析。
3. 檢查套件鎖定結果、已確認的弱點門檻與授權限制。
4. 執行單元測試與不需要外部相依的快速測試。
5. 建置一次正式候選成品，並產生內容識別。
6. 對該成品執行整合、契約、端對端及適用的專項測試。
7. 完成發布核准後，部署同一份成品。
8. 執行部署後檢查並記錄最終結果。

各階段可以在相依關係允許時平行執行，但後續工作只能使用已通過前置條件的輸入。單一非必要報告失敗是否阻擋流程，也要事先分類，不能在失敗發生後才臨時決定。

使用共同指令避免兩套結果

本機與自動化流程應該呼叫相同的專案指令。格式、測試與建置如果只存在於特定平臺的流程檔案，開發人員就難以在提交前重現失敗。共同指令則負責實際工作，自動化工具只安排觸發、執行環境、相依順序與結果保存。

共同指令應該具備下列特性：

• 從乾淨狀態執行，不依賴未記錄的本機檔案或先前輸出。
• 失敗時回傳非成功狀態，並指出檔案、案例或步驟。
• 不需要互動輸入，必要設定由受控來源提供。
• 多次執行產生相同判斷，不會因殘留狀態改變結果。
• 能在選定的執行環境與工具版本中重現。

流程檔案、共用指令與工具版本都要納入版本控制。修改其中一項時，應該使用候選流程驗證新定義，再讓它成為共同版本。

將測試策略轉換成自動化門檻

測試策略已經定義案例層級、執行條件與阻擋範圍。自動化流程要保存這些差異，不能把所有測試都縮成一個只有通過或失敗的步驟。

測試失敗要保留案例識別、目標版本、執行環境、實際結果與相關報告。允許重跑時，還要區分程式缺陷、測試不穩定、環境失敗與相依項目異常。反覆執行直到偶然通過，不能視為穩定結果。

只建置一次並移動同一份成品

準備發布的來源提交應該只建置一次正式候選成品。測試、預備與正式環境使用相同成品，再由各環境提供必要設定。這可以避免不同環境分別建置，使工具或相依差異產生不同內容。

每份成品至少要記錄來源提交、發布版本、流程執行識別與內容摘要。進入下一個環境前，流程應該重新驗證內容識別。GitHub Actions 的工作流程成品與GitLab CI/CD 的工作成品都能在工作之間保存建置輸出及報告。實際保存位置可以不同，但不能依賴容易被覆寫的檔名辨識內容。

測試報告與部署成品要分開管理。報告說明某項檢查結果，部署成品則是實際執行內容。兩者可以由同一次流程產生，保存期限與存取範圍仍可能不同。

分開成品與環境設定

同一份成品移動至不同環境時，不應重新寫入程式內容。環境差異應該透過已定義的設定介面提供，並在啟動前驗證必要欄位、格式與允許值。

• 非敏感設定可以保存版本，或由受控設定來源提供並留下版本識別。
• 敏感設定只在需要的工作與環境中提供，不寫入成品、流程輸出或測試報告。
• 正式環境的設定存取範圍應該與一般建置工作分開。
• 設定變更也要留下時間、範圍、核准與驗證結果。
• 部署紀錄要同時保存成品識別與設定版本，才能重現實際狀態。

如果成品必須因環境不同而重新建置，就要先確認差異是否真的屬於建置內容。確有必要時，每個結果都是不同成品，必須分別產生識別並完成檢查。

安排相容的部署順序

一項發布可能包含多個部署單位、保存結構異動、背景工作或靜態內容。流程要按照相依方向與相容條件安排順序，並考慮新舊版本短時間同時存在的情況。

如果系統包含保存結構異動，可以先採用新舊程式都能接受的擴充變更，再部署使用新結構的程式，最後於確認停止使用後移除舊結構。無法維持相容的異動需要明確停機、停止寫入或其他隔離條件，不能讓自動化工具自行猜測順序。

滾動部署（Rolling Deployment）、藍綠部署（Blue-Green Deployment）與金絲雀發布（Canary Release）只是在特定部署架構下控制替換範圍的方式。採用前要確認部署環境支援、版本相容、狀態保存、觀察門檻及停止方式，不能只因工具提供選項就啟用。

將核准、存取與並行限制放進流程

正式部署應該只允許經過授權的來源、成品與操作方式。部署工作只取得完成該環境工作所需的存取範圍，建置工作不應該預設具有正式部署能力。

自動化平臺可以把核准、分支限制、環境設定與部署紀錄放入流程。例如，GitHub Actions 的部署環境可以設定核准與部署來源限制。選定平臺後，仍要另外確認方案限制、執行器位置、核准責任及敏感設定的可見範圍。

同一環境還要限制並行部署。後一個版本不能在前一個版本尚未完成驗證時直接覆蓋狀態。流程可以使用佇列、互斥或取消過期候選等方式，並明確記錄哪一次部署取得執行權。

部署後驗證實際可用結果

部署指令成功只表示工具完成預定動作。流程還要驗證目標程式能否啟動、是否準備完成，以及關鍵功能是否產生預期結果。

部署後檢查可以分成下列層次：

1. 確認部署平臺回報的版本、成品摘要與目標環境一致。
2. 執行啟動、存活與就緒檢查，確認程序狀態及必要相依條件。
3. 執行冒煙測試（Smoke Testing），以少量固定案例確認關鍵輸入輸出。
4. 如果包含保存結構異動，確認遷移狀態、必要資料與相容結果。
5. 觀察錯誤、延遲、處理量與積壓是否超過部署門檻。
6. 保存版本、案例、觀察期間與最終判斷，再決定完成或擴大部署。

健康檢查與冒煙測試的責任不同。健康檢查適合快速判斷程式是否可被部署平臺使用，冒煙測試則驗證少量關鍵功能。兩者都不能取代完整測試策略。

讓失敗停止在可控制的範圍

每個階段都要定義停止條件與可再次執行的起點。

選擇還原（Rollback）或向前修正（Roll Forward）前，要先確認程式、保存結構與資料變更是否相容。無法安全還原時，流程應該停止新操作、隔離影響或執行已驗證的修正程序。每種處理方式都要事先演練，並且以固定條件判斷完成。

驗證自動化流程本身

流程定義也是目標系統的一部分，需要測試與維護。可以使用不影響正式結果的方式，定期驗證下列情境：

• 模擬程式碼檢查、測試與建置失敗，確認後續工作不會執行。
• 提供錯誤成品摘要，確認部署前會拒絕內容不符的成品。
• 模擬核准缺漏、存取失敗與同環境並行部署，確認保護規則有效。
• 中斷部署步驟後重新執行，確認流程能辨識已完成與待處理範圍。
• 讓健康檢查或冒煙測試失敗，確認停止及復原程序會被啟動。
• 檢查流程紀錄、測試報告與成品保存期限是否符合追查需要。

流程變更也要經過審查。修改觸發條件、略過測試、擴大正式環境存取或改變復原方式，都可能直接改變發布風險，不能只當成設定格式調整。

完成自動化流程的檢查

• 每種觸發方式是否具有明確目的、來源限制與可產生結果？
• 本機與自動化流程是否呼叫相同的檢查、測試與建置入口？
• 可自動執行的測試是否具有觸發時機、通過條件與失敗處理？
• 發布流程是否只建置一次，並將同一份不可變更成品移動至各環境？
• 成品、測試報告、來源提交與發布版本是否可以互相追溯？
• 環境設定是否與成品分開，且敏感內容不會進入輸出紀錄？
• 多個部署單位與保存結構異動是否具有相容順序及停止條件？
• 正式部署是否受到來源、核准、存取範圍與並行數量限制？
• 部署後是否執行健康檢查、冒煙測試、關鍵功能與版本確認？
• 失敗時的停止、還原、切換回既有結果或向前修正程序是否經過演練？
• 流程本身的中斷、重跑與保護規則是否定期驗證？

重點整理

• 自動化流程要把觸發來源、程式碼檢查、分層測試、單次建置、成品核准、部署及部署後驗證串成可追溯的關卡。
• 各環境應該使用同一份不可變更成品，並將設定與成品分開管理。
• 流程在任何階段失敗時都要停止於可控制範圍，再按照已驗證的還原或向前修正程序處理。